home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1581.txt < prev    next >
Text File  |  1994-08-01  |  8KB  |  228 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           G. Meyer
  8. Request for Comments: 1581                                Spider Systems
  9. Category: Informational                                    February 1994
  10.  
  11.  
  12.    Protocol Analysis for Extensions to RIP to Support Demand Circuits
  13.  
  14. Status of this Memo
  15.  
  16.    This document provides information for the Internet community.  This
  17.    document does not specify an Internet standard of any kind.
  18.    Distribution of this document is unlimited.
  19.  
  20. Abstract
  21.  
  22.    As required by Routing Protocol Criteria [1], this report documents
  23.    the key features of Routing over Demand Circuits on Wide Area
  24.    Networks - RIP [2] and the current implementation experience.
  25.  
  26. Acknowledgements
  27.  
  28.    I would like to thank colleagues at Spider, in particular Richard
  29.    Edmonstone and Alan Turland who developed Spider's IP RIP and IPX RIP
  30.    and SAP implementations.
  31.  
  32. 1. Protocol Documents
  33.  
  34.    "Extensions to RIP to Support Demand Circuits" [2] suggests an
  35.    enhancement to the "Routing Internet Protocol" (RIP) [3] and "RIP-2"
  36.    [4] to allow them to run more cost-effectively on Wide Area Networks
  37.    (WANs).  Network management extensions for Demand RIP are described
  38.    in RIP Version 2 MIB Extensions [5].
  39.  
  40. 2. Applicability
  41.  
  42.    Demand RIP requires that there is an underlying mechanism for
  43.    determining unreachability in a finite predictable period.
  44.  
  45.    The demand extensions to RIP are particularly appropriate for WANs
  46.    where the cost - either financial or packet overhead - would make
  47.    periodic transmission of routing (or service advertising) updates
  48.    unacceptable:
  49.  
  50.    o  Connection oriented Public Data Networks - for example X.25 packet
  51.       switched networks or ISDN.
  52.  
  53.    o  Point-to-point links supporting PPP link quality monitoring or
  54.       echo request to determine link failure.
  55.  
  56.  
  57.  
  58. Meyer                                                           [Page 1]
  59.  
  60. RFC 1581                       Demand RIP                  February 1994
  61.  
  62.  
  63.    A demand RIP implementation runs standard RIP on Local Area Networks
  64.    (LANs) allowing them to interoperate transparently with
  65.    implementations adhering to the original specifications.
  66.  
  67. 3. Key Features
  68.  
  69.    The proposal shares the same basic algorithms as RIP or RIP-2 when
  70.    running on LANs or fixed point-to-point links; Packet formats,
  71.    broadcast frequency, triggered update operation and database timeouts
  72.    are all unmodified.
  73.  
  74.    The new features operate on WANs which use switched circuits on
  75.    demand to achieve intermittent connectivity.  Instead of using
  76.    periodic 'broadcasts', information is only sent as triggered updates.
  77.    The proposal makes use of features of the underlying connection
  78.    oriented service to provide feedback on connectivity.
  79.  
  80. 3.1 Triggered Updates
  81.  
  82.    Updates are only sent on the WAN when an event changes the routing
  83.    database.  Each update is retransmitted until acknowledged.
  84.    Information received in an update is not timed out.
  85.  
  86.    The packet format of a RIP response is modified (with a different
  87.    unique command field) to include sequence and fragment number
  88.    information.  An acknowledgement packet is also defined.
  89.  
  90. 3.2 Circuit Manager
  91.  
  92.    The circuit manager running below the IP network layer is responsible
  93.    for establishing a circuit to the next hop router whenever there is
  94.    data (or a routing update) to transfer.  After a period of inactivity
  95.    the circuit will be closed by the circuit manager.
  96.  
  97.    If the circuit manager fails to make a connection a circuit down
  98.    indication is sent to the routing application.  The circuit manager
  99.    will then attempt at (increasing) intervals to establish a
  100.    connection.  When successful a circuit up indication is sent to the
  101.    routing application.
  102.  
  103. 3.3 Presumption of Reachability
  104.  
  105.    In a stable network there is no requirement to propagate routing
  106.    information on a circuit, so if no routing information is (being)
  107.    received on a circuit it is assumed that:
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Meyer                                                           [Page 2]
  115.  
  116. RFC 1581                       Demand RIP                  February 1994
  117.  
  118.  
  119.    o  The most recently received information is accurate.
  120.  
  121.    o  The intervening path is operational (although there may be no
  122.       current connection).
  123.  
  124.    If the circuit manager determines that the intervening path is NOT
  125.    operational routing information previously received on that circuit
  126.    is timed out.  It is worth stressing that it can be ANY routed
  127.    datagram which triggers the event.
  128.  
  129.    When the circuit manager re-establishes a connection, the application
  130.    exchanges full routing information with its peer.
  131.  
  132. 3.4 Routing Information Flow Control
  133.  
  134.    If the circuit manager reports a circuit as down, the routing
  135.    application is flow controlled from sending further information on
  136.    the circuit.
  137.  
  138.    To prevent transmit queue overflow and also to avoid 'predictable'
  139.    circuit down messages, the routing application can also optionally
  140.    limit the rate of sending routing messages to an interface.
  141.  
  142. 4. Implementations
  143.  
  144.    At this stage there is only believed to be one completed
  145.    implementation.
  146.  
  147.    The Spider Systems' implementation supports all the features outlined
  148.    for IP RIP-1, IPX RIP and IPX SAP.  RIP-2 is not currently supported.
  149.    It has been tested against itself on X.25 and ISDN WANs.  It has also
  150.    been tested in operation with various router and host RIP-1, IPX RIP
  151.    and IPX SAP implementations on Ethernet LANs.
  152.  
  153.    Two other Novell-only implementations are known to be under
  154.    development.
  155.  
  156. 5. Restrictions
  157.  
  158.    Demand RIP relies on the ability to place a call in either direction.
  159.    Some dialup services - for example DTR dialing - allow calls to be
  160.    made in one direction only.
  161.  
  162.    Demand RIP can not operate with third-party advertisement of routes
  163.    on the WAN.  The next hop IP address in RIP-2 should always be
  164.    0.0.0.0 for any routes advertised on the WAN.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Meyer                                                           [Page 3]
  171.  
  172. RFC 1581                       Demand RIP                  February 1994
  173.  
  174.  
  175. 6. Security Considerations
  176.  
  177.    Security is provided through authentication of the logical and
  178.    physical address of the sender of the routing update.  Incoming call
  179.    requests are matched by the circuit manager against a list of
  180.    physical addresses (used to make outgoing calls).  The routing
  181.    application makes a further check against the logical address of an
  182.    incoming update.
  183.  
  184.    Additional security can be provided by RIP-2 authentication [2] where
  185.    appropriate.
  186.  
  187. 7. References
  188.  
  189.    [1] Hinden, R., "Internet Engineering Task Force Internet Routing
  190.        Protocol Standardization Criteria", RFC 1264, Bolt Beranek and
  191.        Newman, Inc, October 1991.
  192.  
  193.    [2] Meyer. G., "Extensions to RIP to Support Demand Circuits", RFC
  194.        1582, Spider Systems, February 1994.
  195.  
  196.    [3] Hedrick. C., "Routing Information Protocol", STD 34, RFC 1058,
  197.        Rutgers University, June 1988.
  198.  
  199.    [4] Malkin. G., "RIP Version 2 - Carrying Additional Information",
  200.        RFC 1388, Xylogics, January 1993.
  201.  
  202.    [5] Malkin. G., and F. Baker, "RIP Version 2 MIB Extensions", RFC
  203.        1389, Xylogics, ACC, January 1993.
  204.  
  205. Author's  Address
  206.  
  207.        Gerry Meyer
  208.        Spider Systems
  209.        Stanwell Street
  210.        Edinburgh EH6 5NG
  211.        Scotland, UK
  212.  
  213.        Phone: (UK) 31 554 9424
  214.        Fax:   (UK) 31 554 0649
  215.        EMail: gerry@spider.co.uk
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Meyer                                                           [Page 4]
  227.  
  228.